fix: dedupe identical same-key markDefs on every block merge - #3195

…g text block fragments

`adjustFragmentKeys` renamed a fragment markDef whenever its `_key`
existed on the destination block, on key membership alone. A def that
is byte-identical to the destination's is the same annotation, so the
rename churned identity for nothing: consumers that track annotations
by `_key` (comments, decorations) lost the annotation they were
following, and the caller's plain markDefs append then stored the same
content twice under two keys.

Colliding defs are now compared with `isDeepEqual`: an identical def
keeps its key, is excluded from the defs appended into the
destination, and its spans' `marks` stay untouched, so they resolve
to the destination's copy. Same-key defs with different content rename
exactly as before, pinned by a contrast test that fails when the
equality branch is forced.

One rider: `isDeepEqual` gains an explicit `boolean` return type.
The inferred type predicate narrowed the non-equal branch of same-type
comparisons to `never`, which broke compilation at the new call
site.

`planMergeKeyRenames` carried a required `dedupeEqualMarkDefs`
flag: the range-delete merge deduped identical same-key defs, but the
collapsed backspace/forward-delete merges had to keep renaming them,
because their `renamedBlock` feeds `insert.block`, where
`parseBlock` parses the block standalone and strips any mark that
does not resolve in the block's own `markDefs`: a deduped def's
spans would have lost the annotation entirely.

With `insert.block`'s fragment adjustment now treating identical
defs as non-conflicts, that constraint is gone and the flag deletes.
The planner always keeps an identical same-key def unrenamed and
inside `renamedBlock.markDefs` (the block must carry the def so
`parseBlock` resolves its marks) and reports it in
`dedupedMarkDefKeys`; `mergeBlock` skips appending those keys.

Net behavior change: the collapsed merges now dedupe. Splitting an
annotated block and merging it back rejoins the annotation into one
def under its original key, where it previously duplicated the def and
re-keyed half the spans; the `annotations-across-blocks` gherkin
scenario that pinned the old outcome under a 'possible wrong
behaviour' warning now pins the rejoin, and the `unique-sibling-keys`
pin of the same shape follows. Undo of a deduped merge restores both
original blocks byte-identically, pinned by an undo-redo-undo
round-trip. The range-delete path's behavior is unchanged.